In recent years, the processor architecture has been shifting to the so-called multi-core processor architecture in which a central processing unit (hereinafter, abbreviated as CPU) includes multiple CPU cores packaged onto a single chip. A multi-core CPU is a single CPU when viewed from outside, but is internally regarded as multiple CPUs. Thus, in an environment where a CPU is mainly involved in concurrent processing, the CPU chip as a whole is able to achieve improved performance by enhancing its overall processing capacity. The multi-core processor architecture allows a tremendous increase in the number of hardware threads simultaneously executable by a single processor.
When a conventional program is executed on a processor capable of simultaneously executing multiple threads as described above, the processor has a problem of performance deterioration due to lock contentions. A lock contention mentioned here indicates a state where, when a certain thread acquires a lock in entering a critical section that needs to be exclusively executed, another thread cannot go into the next step until the lock is released. Such a thread that cannot go into the next step usually goes into a spin loop or a sleep state.
There are various factors for causing a lock contention. One of the factors is that program code uses a so-called collection class (hereinafter, referred to as “synchronized collection class”), in which the program code operates while acquiring and releasing a lock to exclusively execute a thread. For example, such program code is code belonging to such synchronized collection class, and involving access to a map class (hereinafter, referred to as “synchronized map class”) for mapping a predetermined key to a certain value. The program code uses an instance object of the synchronized map class to lock all the methods included in the synchronized map class. For this reason, when multiple threads accesses the same synchronized map class, lock contentions occur frequently. Once a lock contention occurs, the processor is allowed to execute only one thread at one time. In this way, the lock contention poses a scalability problem in performance of the processor.
Brian Gortz, “Java theory and practice: Concurrent collections classes,” shows that a Hashtable class as an example of the aforementioned synchronized collection class can be replaced with a ConcurrentHashMap class which enables concurrent operations by minimizing synchronization. For more detailed description of the ConcurrentHashMap class, please see Java™ 2 Platform Standard Ed. 5.0, “ConcurrentHashMap (Java 2 Platform SE 5.0).”
When “Hashtable” in code is simply replaced with “ConcurrentHashMap” by using a replace function of an editor in order to change from the Hashtable class to the ConcurrentHashMap class, such replacement cannot reduce any lock contentions in the following cases: (1) methods in a synchronized map class are enclosed in a synchronized block; (2) a class inherits a Hashtable class (java.util.Hashtable); and (3) a key of the synchronized map class is used as a thread specific value.
Whenever program code causes a problem in performance deterioration due to a lock contention, the program code needs to be corrected manually by identify the factor of the lock contention. However, doing such a correction work is almost impossible because a huge amount of workload is needed due to a large amount of the program code currently existing. For this reason, there is needed a method of automatically identifying and correcting in advance a section where the foregoing problem is likely to occur. In addition, for changing from a Hashtable class to a ConcurrentHashMap class, it is necessary to prepare an algorithm which enables automatic replacement with a synchronized map class while avoiding the problem of the lock contention.